VMware PowerCLI – это весьма мощный инструмент управления, а всё, что нужно сделать для начала работы с ним - это подключиться к серверу или серверам виртуальной инфраструктуры, которыми могут являться сервер управления vCenter Server, Linux vCenter Server Appliance (vCSA) или ESXi-хост.

Странные вещи происходят в последнее время с VMware. Сначала в технологии Changed Block Tracking (CBT) платформы VMware vSphere 6 был найдет серьезный баг, заключавшийся в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Из-за этого пользователи переполошились не на шутку, ведь бэкапы, а это критически важная составляющая инфраструктуры, могли оказаться невосстановимыми.

Недавно этот баг был пофикшен в обновлении ESXi600-201511401-BG, и вроде бы все стало окей. Но нет - оказалось, что накатить обновление на ваши серверы VMware ESXi недостаточно, о чем своевременно сообщила компания Veeam (официальная KB находится вот тут). Нужно еще и сделать операцию "CBT reset", то есть реинициализировать Changed Block Tracking для виртуальных машин.

Все дело в том, что уже созданные файлы CBT map могут содержать невалидные данные, касательно изменившихся блоков, а ведь они могли быть созданы еще до накатывания патча от VMware. Таким образом, простое обновление ESXi не убирает потенциальную проблему - старые файлы *-ctk.vmdk могут, по-прежнему, быть источником проблем. Удивительно, как такая могучая компания как VMware просто взяла и прошляпила этот момент.

Итак, как нужно делать CBT reset для виртуальной машины описано вот тут у Veeam. Приведем этот процесс вкратце:

1. Открываем настройки виртуальной машины (да-да, для каждой ВМ придется это делать) и идем в Configuration Parameters:

2. Там устанавливаем значение параметра:

ctkEnabled = false

3. Далее устанавливаем

scsi0:x.ctkEnabled также в значение false:

4. Открываем папку с виртуальной машиной через Datastore Browser и удаляем все файлы *-ctk.vmdk (это и есть CBT map файлы):

5. Включаем виртуальную машину и заново запускаем задачу резервного копирования Veeam Backup and Replication.

Для тех, кто умеет пользоваться интерфейсом PowerCLI есть бонус - компания Veeam сделала PowerShell-скрипт, который автоматизирует эту операцию. Он позволяет переинициализировать CBT для указанных пользователем виртуальных машин. Виртуальные машины со снапшотом, а также выключенные ВМ будут проигнорированы. Также надо отметить, что при выполнении сценария создается снапшот машины, а потом удаляется, что может вызвать временное "подвисание" машины и ее недоступность в течение некоторого времени, поэтому лучше выполнять этот скрипт ночью или в нерабочие часы.

Компания Код Безопасности подготовила своим пользователям и потенциальным клиентам отличный подарок под новый год - полностью обновленный продукт для защиты виртуальных сред vGate for Hyper-V, которые позволяет защитить вашу виртуальную инфраструктуру Microsoft от несанкционированного доступа и безопасно сконфигурировать ее средствами политик безопасности. Теперь vGate поддерживает средство управления виртуальными машинами System Center Virtual Machine Manager (SC VMM) от компании Microsoft.

Многие из вас, следящие за новостями о лучшем продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, часто задаются вопросом - а чем это решение лучше существующих аналогов от VMware и Microsoft? Первый и наиболее очевидный ответ - цена. Просто посмотрите на то, сколько стоит VMware VSAN, и сравните это со стоимостью лицензий StarWind. Разницу вы почувствуете сразу.

Но это еще не все. Компания StarWind выпустила полезный каждому сомневающемуся документ "StarWind Virtual SAN: Differentiation [from competitors]", в котором весьма подробно рассмотрены преимущества продукта перед решениями от маститых вендоров.

Например, почему StarWind Virtual SAN лучше VMware Virtual SAN:

• Для работы отказоустойчивых хранилищ StarWind нужно всего 2 узла (VMware требует минимум 3). Плюс StarWind не требует какой-то особенной инфраструктуры типа поддержки 10G Ethernet или SSD-дисков. У StarWind все проще.
• VMware Virtual SAN лицензируется по числу процессоров ESXi плюс требуются лицензии на сам ESXi. У StarWind лицензия выйдет дешевле - вы можете лицензировать по числу узлов кластера хранилищ, либо весь датацентр сразу, и использовать бесплатные издания ESXi.
• Кластер VMware Virtual SAN вы можете использовать только для платформы vSphere, а StarWind Virtual SAN можно использовать для хранения виртуальных машин на базе любого гипервизора - хоть ESXi, хоть Hyper-V, хоть XenServer.
• StarWind Virtual SAN - это продукт, который сейчас находится в 8-й версии, а Virtual SAN - это всего лишь вторая версия решения. Поскольку это решение относится к самому нижнему уровню сервисов хранения датацентра, надежность работы решения является определяющим факторов.

Более подробно об этом и других продуктах для сравнения, в частности, Microsoft Storage Spaces, Microsoft Scale-Out File Server, HP Lefthand VSA, DataCore SANsymphony, Maxta и PernixData, вы можете узнать непосредственно из документа.

Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.

Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.

И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.

Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:

ESXi600-201511401-BG

Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:

Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:

# esxcli software vib install -d "/vmfs/volumes/Datastore/DirectoryName/PatchName.zip"

Более подробно об установке VIB-пакетов написано тут.

Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).

SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.

SSD-диски значительно более производительны в плане IOPS (тысячи и десятки тысяч операций в секунду), поэтому их удобно использовать для кэширования. Это выгодно и с экономической точки зрения (доллары на IOPS), об этом в документе есть наглядная табличка:

То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.

Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.

Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.

Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.

Итак, как именно работает кэширование на SSD в VMware Virtual SAN:

1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.

2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).

3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.

4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.

5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.

6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.

В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!

Представляем вашему вниманию гостевой пост компании ИТ-ГРАД - ведущего российского сервис-провайдера, оказываюшего услуги по аренде виртуальных машин VMware. Предлагаем вашему вниманию отчет о поездке сотрудников ИТ-ГРАД на VMworld Europe 2015.

В этом материале мы решили сделать акцент на технической части мероприятия как наиболее интересной читателю. В самом деле, все эти лаундж-зоны, подарочные рюкзаки и игры в теннис бесполезно описывать словами — в этом надо участвовать. Итак, поехали…

Основная составляющая любой подобной конференции — технические доклады. Именно ради полезной и интересной информации тысячи людей по всему миру стараются попасть на мероприятия вроде VMworld (кроме единичных исключений, оказавшихся там волей случая). Являясь новаторской компанией, VMware не разочаровала своих пользователей и поклонников, представив несколько действительно интересных разработок.

Особенно понравилось, что компания решила отойти от типичного формата «сессия на целый час» и не утомлять слушателей докладами, обильно разбавленными «водичкой». Сессии длились в среднем по 30 минут и были максимально избавлены от ненужной и повторяющейся информации. Браво, VMware! ->> нажмите, чтобы читать дальше и комментировать ->>

На сайте проекта VMware Labs, где сотрудники VMware частенько публикуют различного рода утилиты для инфраструктуры VMware vSphere, появилось обновление очень полезной штуки, которое все очень давно ждали - VMware Auto Deploy GUI. Напомним, что о прошлой верcии этого средства мы писали вот тут.

Теперь вы можете проводить преднастройку профилей и развертывание новых хостов VMware ESXi 6 для Stateless-окружения прямо из графического интерфейса VMware vSphere Client:

Auto Deploy GUI - это плагин к vSphere Client, реализующий основные функции VMware vSphere Auto Deploy, такие как:

• Добавление/удаление хранилищ (depots).
• Работа с профилями образов (image profiles).
• Настройка шаблона файла ответов (answer template).
• Просмотр свойств VIB-пакетов.
• Создание/редактирование правил соответствия хостов и профилей образов.
• Проверка соответствия хостов этим правилам и восстановление этого соответствия.

Новые возможности последней версии Auto Deploy GUI:

• Поддержка VMware vSphere 6.0.
• В мастере Image Profile Wizard появились новые функции "VIB filter".
• Новые средства "PXE Host List and Boot Configuration troubleshooting" для решения проблем с загрузкой хостов.

Надо отметить, что это последняя версия Auto Deploy GUI, которая поддерживает VMware vSphere версии 5.0. Скачать VMware Auto Deploy GUI можно по этой ссылке. Ну и порекомендуем очень полезный документ "VMware Auto Deploy GUI Practical Guide".

Как-то раз мы писали про баг в VMware vSphere 5.5 (и более ранних версиях), заключавшийся в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT) их резервные копии оказывались невалидными и не подлежащими восстановлению. Эта ошибка была через некоторое время пофикшена.

Однако похожая (но только еще более тяжелая) судьба постигла и свежую версию платформы виртуализации VMware vSphere 6 - технология CBT также портит резервные копии виртуальных машин любого решения для резервного копирования, использующего отслеживание изменившихся блоков, например, Veeam Backup and Replication. Более подробно проблема изложена в KB 2136854.

Суть критического бага в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могут быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывает потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап будет неконсистентным. То есть баг намного более серьезный, чем был в версии vSphere 5.5 (там надо были задеты только ВМ, диски которых увеличивали, а тут любая ВМ подвержена багу).

На данный момент решения этой проблемы нет, надо ждать исправления ошибки. Пока VMware предлагает на выбор 3 варианта:

• Сделать даунгрейд хостов ESXi на версию 5.5, а версию virtual hardware 11 понизить на 10.
• Делать полные бэкапы виртуальных машин (full backups) вместо инкрементальных.
• Выключать виртуальные машины во время инкрементального бэкапа, чтобы у них не было никаких IO, которые могут потеряться.

Как вы понимаете, ни один из этих вариантов неприемлем в условиях нормальной работы производственной среды. Мы оповестим вас об исправлении ошибки, ну а пока поздравляем службу контроля качества компании VMware с очередной лажей!

P.S. Пока делайте полные бэкапы критичных систем. И следите за новостями от Veeam.

Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.

3 года назад мы писали об утилите ESXi5 Community Packaging Tools 2.0, которая позволяет создавать собственные пакеты для VMware ESXi в форматах VIB (VMware Installation Bundle) and ZIP (VMware Offline Bundle). В результате VIB-файлы получают уровень доверия (acceptance level) Community Supported. Зачастую, эти утилиты необходимы пользователям для включения сторонних драйверов устройств в состав дистрибутива платформы ESXi, которые отсутствуют в стандартном комплекте поставки.

На днях автор проекта (и он же блоггер на v-front.de) выпустил обновление этого средства - ESXi Community Packaging Tools 2.3.

На самом деле, изменений было сделано не так много, но они есть и важные:

• Появилась полная поддержка VMware vSphere 6 (именно поэтому "ESXi5 Community Packaging Tools" (ESXi5-CPT) переименованы в "ESXi Community Packaging Tools" (ESXi-CPT).
• Пакетный сценарий TGZ2VIB5.cmd обновлен до версии 2.3.
  • Пофикшено название уровня доверия (acceptance level) "certified" (раньше он назывался "vmware").
  • Добавлены пресеты конфигураций "ESXi 6.0+ driver" и "VMware Tools" (tools-light.vib). Теперь вы можете создать свой пакет VMware Tools для распространения в гостевых ОС на базе гипервизора ESXi!
  • Добавлена поддержка типа VIB-пакета (vibType) "locker".
• Пакетный файл VIB2ZIP.cmd обновился до версии 1.3 - туда были добавлен выбор настроек совместимости для VMware ESXi.

Видео о создани VMware Offline Bundle с помощью VIB2ZIP:

Скачать ESXi Community Packaging Tools версии 2.3 можно по этой ссылке.

Как некоторые из вас знают, сейчас в разработке у VMware находится новая версия продукта Virtual SAN (о текущей версии VSAN 6.1 мы писали вот тут), а скоро появится ее бета. Дункан написал пару интересных постов о том, какие возможности для экономии дискового пространства появятся в новой версии Virtual SAN.

А именно:

• erasure coding
• deduplication
• compression

Обещают, что эти 3 вещи уменьшат потребляемое дисковое пространство в разы. Давайте посмотрим на некоторые детали этих возможностей.

Erasure coding (коррекция ошибок - "RAID из узлов")

Сейчас если вы используете параметр failures to tolerate =1 (зеркальная избыточность), то вам нужна двойная емкость в кластере. То есть, если будет 100 ГБ под виртуальные машины, то на хостах суммарная емкость должна составлять 200 ГБ.

По аналогии с RAID5/6 и другими типами RAID с чередованием, пространство хранения Virtual SAN будет представлять собой "RAID из хостов ESXi". Таким образом, можно будет использовать схемы 3+1 или 4+2, которые позволят иметь лишь в 1,3 раза больше физического пространства (для первой схемы), чем полезной емкости.

Но, понятное дело, для таких схем понадобится несколько больше хостов, чем, например, два.

Deduplication (дедупликация блоков)

Дедупликация блоков будет работать на уровне дисковой группы. Коэффициент дедупликации зависит от характера и разнообразия данных виртуальных машин, но при тестах он доходил до 8x.

Compression (сжатие данных)

Здесь каждый vmdk будет хранить только оригинальные дисковые блоки:

Ожидается, что для каждого 4KB блока в среднем удастся сэкономить 2KB.

Сделать запрос на бета-версию VMware Virtual SAN можно по этой ссылке.

На блоге vSphere появилась отличная статья о сервисах семейства vCenter Server Watchdog, которые обеспечивают мониторинг состояния различных компонентов vCenter, а также их восстановление в случае сбоев. Более подробно о них также можно прочитать в VMware vCenter Server 6.0 Availability Guide.

Итак, сервисы Watchdog бывают двух типов:

• PID Watchdog - мониторит процессы, запущенные на vCenter Server.
• API Watchdog - использует vSphere API для мониторинга функциональности vCenter Server.

Сервисы Watchdog пытаются рестартовать службы vCenter в случае их сбоя, а если это не помогает, то механизм VMware перезагружает виртуальную машину с сервером vCenter на другом хосте ESXi.

PID Watchdog

Эти службы инициализируются во время инициализации самого vCenter. Они мониторят только службы, которые активно работают, и если вы вручную остановили службу vCenter, поднимать он ее не будет. Службы PID Watchdog, контролируют только лишь наличие запущенных процессов, но не гарантируют, что они будут обслуживать запросы (например, vSphere Web Client будет обрабатывать подключения) - этим занимается API Watchdog.

Вот какие сервисы PID Watchdog бывают:

• vmware-watchdog - этот watchdog обнаруживает сбои и перезапускает все не-Java службы на сервере vCenter Server Appliance (VCSA).
• Java Service Wrapper - этот watchdog обрабатывает сбои всех Java-служб на VCSA и в ОС Windows.
• Likewise Service Manager - данный watchdog отвечает за обработку отказов всех не-Java служб сервисов platform services.
• Windows Service Control Manager - отвечает за обработку отказов всех не-Java служб на Windows.

vmware-watchdog

Это шелл-скрипт (/usr/bin/watchdog), который располагается на виртуальном модуле VCSA. Давайте посмотрим на его запущенные процессы:

mgmt01vc01.sddc.local:~ # ps -ef | grep vmware-watchdog

root      5767     1  0 16:20 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s rhttpproxy -u 30 -q 5 /usr/sbin/rhttpproxy -r /etc/vmware-rhttpproxy/config.xml -d /etc/vmware-rhttpproxy/endpoints.conf.d -f /etc/vmware-rhttpproxy/endpo
root      7930     1  0 16:21 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vws -u 30 -q 5 /usr/lib/vmware-vws/bin/vws.sh
root      8109     1  0 16:21 ?        00:00:11 /bin/sh /usr/bin/vmware-watchdog -s syslog -u 30 -q 5 -b /var/run/rsyslogd.pid /sbin/rsyslogd -c 5 -f /etc/vmware-rsyslog.conf
root      8266     1  0 16:21 ?        00:00:11 /bin/sh /usr/bin/vmware-watchdog -b /storage/db/vpostgres/postmaster.pid -u 300 -q 2 -s vmware-vpostgres su -s /bin/bash vpostgres -c 'LD_LIBRARY_PATH=/opt/vmware/vpostgres/curre
root      9422     1  0 16:21 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -a -s vpxd -u 3600 -q 2 /usr/sbin/vpxd
root     13113     1  0 16:22 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vsan-health -u 600 -q 10 su vsan-health -c '/opt/vmware/bin/vmware-vsan-health /usr/lib/vmware-vpx/vsan-health/VsanHealthServer.py -p 8006'
root     28775 19850  0 20:42 pts/0    00:00:00 grep vmware-watchdog

В понятном виде это можно представить так:

Давайте разберем эти параметры на примере наиболее важной службы VPXD:

-a
-s vpxd
-u 3600
-q 2

Это означает, что:

vpxd (-s vpxd) запущен (started), для него работает мониторинг, и он будет перезапущен максимум дважды в случае сбоя (-q 2). Если это не удастся в третий раз при минимальном аптайме 1 час (-u 3600 - число секунд), виртуальная машина будет перезагружена (-a).

Полный список параметров представлен ниже:

-d = DAEMONIZE
-n = QUIET
-b = BG_PROC-s = START
-k = STOP
-r = QUERY
-a = REBOOT_FLAG
-u = MIN_UPTIME
-q = MAX_QUICK_FAILURES
-t = MAX_TOTAL_FAILURES
-i = IMMORTAL
-c = CLEANUP_CMD
-f = EXIT_CLEANUP_CMD

Java Service Wrapper

Он основан на Tanuki Java Service Wrapper и нужен, чтобы обнаруживать сбои в Java-службах vCenter (как обычного, так и виртуального модуля vCSA). Вот какие службы мониторятся:

mgmt01vc01.sddc.local:~ # ps -ef | grep tanuki

cm        6331  6324  0 16:20 ?        00:00:37 /usr/java/jre-vmware/bin/vmware-cm -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=cm-log4j.properties -Dxml.config=ht
root      6876  6869  0 16:20 ?        00:00:50 /usr/java/jre-vmware/bin/vmware-cis-license -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=TRUE -XX:+ForceTimeHighRe
root      7267  7258  1 16:21 ?        00:03:45 /usr/java/jre-vmware/bin/vmware-sca -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lo
root      7634  7627  0 16:21 ?        00:00:29 /usr/java/jre-vmware/bin/vmware-syslog-health -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -DlogDir=/var/log/vmware/syslog -Dlog4j.config
1002      7843  7836  0 16:21 ?        00:01:08 /usr/java/jre-vmware/bin/vmware-vapi-endpoint -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=file:/etc/vmware-vapi//e
root      8453  8433  1 16:21 ?        00:02:55 /usr/java/jre-vmware/bin/vmware-invsvc -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dvim.logdir=/var/log/vmware/invsvc -XX:+ForceTimeHighResolution -XX:+ParallelRefP
root     10410 10388  0 16:22 ?        00:00:54 /usr/java/jre-vmware/bin/vmware-sps -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dxml.config=../conf/sps-spring-config.xml -Dpbm.config=../conf/pbm-spring-config.xml
1007     11099 11088  0 16:22 ?        00:01:27 /usr/java/jre-vmware/bin/vmware-vpx-workflow -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -ea -Dlog4j.configuration=conf/workflow.log4j.p
root     23423 19850  0 20:41 pts/0    00:00:00 grep tanuki

Если Java-приложение или JVM (Java Virtual Machine) падает, то перезапускается JVM и приложение.

Likewise Service Manager

Это сторонние средства Likewise Open stack от компании BeyondTrust, которые мониторят доступность следующих служб, относящихся к Platform Services среды vCenter:

• VMware Directory Service (vmdir)
• VMware Authentication Framework (vmafd, который содержит хранилище сертификатов VMware Endpoint Certificate Store, VECS)
• VMware Certificate Authority (vmca)

Likewise Service Manager следит за этими сервисами и перезапускает их в случае сбоя или если они вываливаются.

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm list | grep vm
vmafd       running (standalone: 5505)
vmca        running (standalone: 5560)
vmdir        running (standalone: 5600)

Вместо параметра list можно также использовать start и stop, которые помогут в случае, если одна из этих служб начнет подглючивать. Вот полный список параметров Likewise Service Manager:

list          List all known services and their status
autostart       Start all services configured for autostart
start-only <service>    Start a service
start <service>            	Start a service and all dependencies
stop-only <service>    Stop a service
stop <service>             Stop a service and all running dependents
restart <service>          Restart a service and all running dependents
refresh <service>         Refresh service's configuration
proxy <service>           Act as a proxy process for a service
info <service>             Get information about a service
status <service>          Get the status of a service
gdb <service>              Attach gdb to the specified running service

А вот таким образом можно узнать детальную информацию об одном из сервисов:

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm info vmdir
Service: vmdir
Description: VMware Directory Service
Type: executable
Autostart: yes
Path: /usr/lib/vmware-vmdir/sbin/vmdird
Arguments: '/usr/lib/vmware-vmdir/sbin/vmdird' '-s' '-l' '0' '-f' '/usr/lib/vmware-vmdir/share/config/vmdirschema.ldif'
Environment:
Dependencies: lsass dcerpc vmafd

Помните также, что Likewise Service Manager отслеживает связи служб и гасит/поднимает связанные службы в случае необходимости.

API Watchdog

Этот сервис следит через vSphere API за доступностью самого важного сервиса vCenter - VPXD. В случае сбоя, этот сервис постарается 2 раза перезапустить VPXD, и если это не получится - он вызовет процедуру перезапуска виртуальной машины механизмом VMware HA.

Эти службы инициализируются только после первой загрузки после развертывания или обновления сервисов vCenter. Затем каждые 5 минут через vSphere API происходит аутентификация и опрос свойства rootFolder для корневой папки в окружении vCenter.

Далее работает следующий алгоритм обработки отказов:

• Первый отказ = Restart Service
• Второй отказ = Restart Service
• Третий отказ = Reboot Virtual Machine
• Сброс счетчика отказов происходит через 1 час (3600 секунд)

Перед рестартом сервиса VPXD, а также перед перезагрузкой виртуальной машины, служба API Watchdog генерирует лог, который можно исследовать для решения проблем:

• storage/core/*.tgz - на виртуальном модуле VCSA
• C:\ProgramData\VMware\vCenterServer\data\core\*.tgz - не сервере vCenter

Конфигурация сервиса API Watchdog (который также называется IIAD - Interservice Interrogation and Activation Daemon) хранится в JSON-формате в файле "iiad.json", который можно найти по адресу /etc/vmware/ на VCSA или C:\ProgramData\VMware\vCenterServer\cfg\iiad.json на Windows-сервер vCenter:

mgmt01vc01.sddc.local:/ # cat /etc/vmware/iiad.json
{
"requestTimeout": 20,
"hysteresisCount": 4,
"remediatedHysteresisCount": 6,
"rebootShellCmd": null,
"restartShellCmd": null,
"maxTotalFailures": 50,
"needShellOnWin": true,
"watchdogDisabled": false,
"vpxd.watchdogDisabled": false,
"createSupportBundle": true,
"automaticServiceRestart": true,
"automaticSystemReboot": false,
"maxSingleRestarts": 3,
"maxSingleFailures": 2
}

Вот что это значит:

• requestTimeout – дефолтный таймаут для запросов по умолчанию.
• hysteresisCount – позволяет отказам постепенно "устаревать" - каждое такое значение счетчика при отказе, число отсчитываемых отказов будет уменьшено на один.
• rebootShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском ВМ.
• restartShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском сервиса.
• maxTotalFailures – необходимое число отказов по всем службам, которое должно случиться, чтобы произошел перезапуск виртуальной машины.
• needShellOnWin – определяет, нужно ли запускать сервис с параметром shell=True на Windows.
• watchdogDisabled – позволяет отключить API Watchdog.
• vpxd.watchdogDisabled – позволяет отключить API Watchdog для VPXD.
• createSupportBundle – нужно ли создавать support-бандл перед перезапуском сервиса или рестартом ВМ.
• automaticServiceRestart – нужно ли перезапускать сервис при обнаружении сбоя или просто записать это в лог.
• automaticSystemReboot – нужно ли перезапускать ВМ при обнаружении сбоя или просто записать в лог эту рекомендацию.
• maxSingleRestarts – верхний лимит попыток перезапуска упавшего сервиса.
• maxSingleFailures – число отказов, требуемой для срабатывания действия по перезапуску сервиса.

Также сервис IIAD перед перезапуском сервисов или виртуальной машины генерирует лог по адресу:

• /var/log/vmware/iiad/* - на виртуальном модуле VCSA
• %VMWARE_LOG_DIR%/iiad/* - в ОС Windows

Вот такой небольшой deep dive в службы доступности сервисов vCenter:)

Многие из вас знают утилиту esxtop (о которой мы часто пишем), позволяющей осуществлять мониторинг производительности сервера VMware ESXi в различных аспектах - процессорные ресурсы, хранилища и сети. Многие администраторы пользуются ей как раз для того, чтобы решать проблемы производительности.

Но оказывается, что использование esxtop само по себе может тормозить работу сервера VMware ESXi!

Это может произойти в ситуации, если у вас к ESXi смонтировано довольно много логических томов LUN, на обнаружение которых требуется более 5 секунд. Дело в том, что esxtop каждые 5 секунд повторно инициализирует объекты, с которых собирает метрики производительности. В случае с инициализацией LUN, которая занимает длительное время, запросы на инициализацию томов будут складываться в очередь. А как следствие (при большом числе томов) это будет приводить к возрастанию нагрузки на CPU и торможению - как вывода esxtop, так и к замедлению работы сервера в целом.

Выход здесь простой - надо использовать esxtop с параметром -l:

# esxtop -l

В этом случае данная утилита ограничит сбор метрик производительности только теми объектами, которые были обнаружены при первом сканировании. Соответственно, так лучше всего ее и использовать, если у вас к серверу VMware ESXi прицеплено много хранилищ.

Продолжаем серию статей о решении vGate R2 от компании Код Безопасности, предназначенном для защиты виртуальной инфраструктуры VMware vSphere и Microsoft Hyper-V от несанкционированного доступа, а также для ее безопасной настройки средствами политик. Сегодня мы поговорим о новой возможности vGate R2 версии 2.8 - режимах работы, которые позволяют обеспечивать развертывание решения, его эксплуатацию, а также обработку исключительных ситуаций.

Мы уже не раз писали про VMware ESXi Embedded Host Client, который возвращает полноценный веб-клиент для сервера VMware ESXi с возможностями управления хостом и виртуальными машинами, а также средствами мониторинга производительности.

Совсем недавно на сайте проекта VMware Labs была опубликована третья версия этого полезнейшего средства - VMware ESXi Embedded Host Client Fling v3.

Теперь для этого продукте есть offline bundle, который можно накатывать с помощью VMware Update Manager, как на VMware vSphere 5.x, так и на VMware vSphere 6.x.

Одна из долгожданных фичей этого релиза - возможность просматривать и редактировать разделы дисков ESXi:

Если у вас есть это средство второй версии, то обновиться на третью можно с помощью следующей команды:

[root@mini:~] esxcli software vib update -v /esxui-signed.vib
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: VMware_bootbank_esx-ui_0.0.2-0.1.3172496
VIBs Removed: VMware_bootbank_esx-ui_0.0.2-0.1.3015331
VIBs Skipped:

Новые возможности VMware ESXi Embedded Host Client Fling v3:

Виртуальные машины

• Поддержка ответа на вопрос интерфейса (Answer question)
• Поддержка виртуального железа (Virtual Hardware) на самую последнюю версию, поддерживаемую хостом ESXi
• Горячее редактирование настроек ВМ
• Настройка колонок в конфигурации (показать/спрятать/ширина), которая сохраняется при рефреше страницы
• Настройка приоритета VM startup/shutdown

Хост ESXi

• Изменение политики электропитания (power management policy) и расширенные ее настройки
• Генерация запроса на подпись IP/FQDN-сертификатом и импорт сертификата
• Добавление хоста к контроллеру домена

Хранилища

• Редактор разделов диска хоста
• Рескан для обнаружения новых LUN и изменений в старых
• Обнаружение новых томов VMFS
• Очистка таблицы разделов на диске
• Диаграмма разбиения разделов диска
• Возможность увеличения хранилища для диска, у которого уже есть таблица разделов

Графики производительности

• Возможность изменять цвета диаграмм (дефолтная схема и высококонтрастная)
• Добавлены графики Network и Disk в разделе производительности
• Улучшенное быстродействие интерфейса
• Улучшенная производительность на планшетах
• Возможность спрятать верхнюю легенду на диаграмме
• Возможность спрятать виджет для расчистки места

Основное

• In-app update tool: возможность обновлять самого себя, просто подставив обновленный VIB-пакет
• Запоминается выбранная вкладка на планшете при навигации
• Более плавный скроллинг на планшетах
• Возможность спрятать интерфейс навигатора, оставив быстрые кнопки Host, Host Manage, Host Monitor, VMs, Storage и Networking
• Кнопка закрытия в менюшках
• Переподключение к консоли при потере соединения к ВМ или при откатывании к снапшоту
• Множественные багофиксы

Скачать VMware ESXi Embedded Host Client Fling v3 можно по этой ссылке.

За прошедшие недели мы достаточно много писали о новостях с VMware VMworld 2015 (как в Америке, так и в Европе). Не так давно компания ИТ-ГРАД, ведущий хостинг-провайдер VMware IaaS в России, опубликовала свою версию основных новостей с VMworld.

Давайте посмотрим, какие анонсы показались коллегам наиболее важными:

15 самых горячих технологических новинок с VMworld 2015

Многие годы VMware формирует будущее корпоративных ИТ-технологий, продвигая идею программно-определяемого ЦОД. Несмотря на растущую конкуренцию, компания до сих пор занимает лидирующие позиции на рынке виртуализации. Столь продвинутую и технически совершенную виртуальную инфраструктуру помогают формировать и многочисленные стратегические партнеры VMware, представившие свои новинки на недавно отгремевшей конференции VMworld 2015. Мы не могли пройти мимо любопытного списка технических новшеств конференции, который опубликовали коллеги из cio.com, и отобрали 15 самых интересных новинок. Спешим поделиться.

1. Unity EdgeConnect

Если попытаться одной фразой объяснить, что делает это устройство, то получится как-то так: Unity EdgeConnect позволяет компаниям упростить и удешевить построение WAN с помощью использования технологий SD-WAN для существующего широкополосного подключения. Фактически требуется подключить такие устройства с обеих сторон (в головном офисе и филиале) и через Unity Orchestrator выполнить связь устройств буквально в пару кликов. Впрочем, лучше посмотреть своими глазами — вот коротенькое видео.

Unity EdgeConnect уже доступен для заказа и обойдется примерно в $199/мес. для каждого сайта.

2. Soha Cloud

Облако Soha Cloud позволяет добавить безопасности вашим облачным приложениям. Продукт выступает в качестве «прослойки» (AirGAP) между облачными приложениями и сетью Интернет, что уменьшает поверхность потенциальной атаки до нуля и прячет приложения от публики. Подробности о технологии можно почерпнуть на сайте SOHA.

Стоимость сервиса стартует с отметки $5/мес. на пользователя, а опробовать его можно уже сейчас.

3. PRTG Network Monitor

PRTG Network Monitor — это система мониторинга для стартапов и небольших компаний. Продукт позволяет выполнять мониторинг состояния и производительности всей инфраструктуры, включая облако и виртуальную среду (например, есть «сенсоры» для серверов VMware и виртуальных машин). Стоимость лицензии зависит от приобретаемого числа сенсоров, причем до 100 штук можно мониторить совершенно бесплатно.

Нажимайте читать дальше ->>

Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.

На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:

В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.

Напомним, что:

• Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
• Shares - доля машины в общей полосе всех хостов ESXi.
• Limit - верхний предел в IOPS, которые машина может потреблять.

А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:

Общий пул Shares = 1000+2500+500+1000 = 5000

Значит каждая машина может рассчитывать на такой процент канала:

VM1 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS
VM2 = 2500/5000 = 50% = 0,5 * 8000 = 4000 IOPS
VM3 = 500/5000 = 10% = 0,1 * 8000 = 800 IOPS
VM4 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS

Если смотреть с точки зрения хостов, то между ними канал будет поделен следующим образом:

ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%

А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.

Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.

Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:

VM1 = 10 IOPS
VM2 = 4000+1000 = 5000 IOPS (так как установлен Limit)
VM3 = 800 + ((500/1500) * 590) = 997 IOPS
VM4 = 1600 + ((1000/1500) * 590) = 1993 IOPS

Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.

Мы часто пишем о проблемах вложенной виртуализации (nested virtualization), которая представляет собой способ запустить виртуальные машины на гипервизоре, который сам установлен в виртуальной машине. На платформе VMware ESXi эта проблема давно решена, и там nested virtualization работает уже давно, мало того - для виртуального ESXi есть даже свои VMware Tools.

Как мы недавно писали, решения для вложенной виртуализации на платформе Microsoft Hyper-V не было. При попытке запустить виртуальную машину на виртуальном хосте Hyper-V администраторы получали вот такую ошибку:

VM failed to start. Failed to start the virtual machine because one of the Hyper-V components is not running.

Все это происходило из-за того, что Microsoft не хотела предоставлять виртуальным машинам средства эмуляции техник аппаратной виртуализации Intel VT и AMD-V. Стандартная схема виртуализации Hyper-V выглядела так:

Virtualization Extensions передавались только гипервизору хостовой ОС, но не гостевой ОС виртуальной машины. А без этих расширений виртуальные машины в гостевой ОС запущены быть не могли.

В Windows 10 Build 10565 (этот превью-билд можно скачать по этой ссылке для x64 и по этой для x86) компания Microsoft, наконец-то, решила поменять ситуацию: теперь Virtualization Extensions передаются в гостевую ОС:

Соответственно, это позволит запустить вложенные виртуальные машины на хосте, который сам является виртуальной машиной с гостевой ОС Windows и включенной ролью Hyper-V.

На данный момент работает это только с Intel VT, но по идее к релизу Windows Server 2016 должно заработать и для AMD-V.

Сфера применения вложенных виртуальных машин не такая уж и узкая. Сейчас видится 2 основных направления:

• Виртуальные тестовые лаборатории, где развертываются виртуальные серверы Hyper-V и строятся модели работающих виртуальных инфраструктур в рамках одного физического компьютера.
• Использование контейнеризованных приложений (например, на движке Docker) в виртуальных машинах на виртуальных хостах Hyper-V. Более подробно о Windows Server Containers можно почитать вот тут. Немногим ранее мы писали об аналогичной архитектуре на базе VMware vSphere, анонсированной на VMware VMworld 2015.

Надо отметить, что для вложенных виртуальных машин не поддерживаются следующие операции (как минимум):

• Dynamic Memory
• Горячее изменение памяти работающей ВМ
• Снапшоты
• Live Migration
• Операции save/restore

Ну и вообще, вряд ли вложенная виртуализация вообще когда-нибудь будет полностью поддерживаться в производственной среде. Кстати, вложенная виртуализация на сторонних гипервизорах (например, VMware vSphere) также не поддерживается.

Для того, чтобы вложенная виртуализация заработала, нужно:

1. Использовать Windows 10 Build 10565. Windows Server 2016 Technical Preview 3 (TPv3) и Windows 10 GA - не подойдут, так как в них возможности Nested Virtualization нет.

2. Включить Mac Spoofing на сетевом адаптере виртуального хоста Hyper-V, так как виртуальный коммутатор хостового Hyper-V будет видеть несколько MAC-адресов с этого виртуального адаптера.

3. В Windows 10 нужно отключить фичу Virtualization Based Security (VBS), которая предотвращает трансляцию Virtualization Extensions в виртуальные машины.

4. Предусмотреть память под сам гостевой гипервизор и под все запущенные виртуальные машины. Память для гипервизора можно рассчитать так:

Теперь для того чтобы включить Nested Virtualization, выполните следующий сценарий PowerShell (в нем и VBS отключается, и Mac Spoofing включается):

Invoke-WebRequest https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-tools/Nested/Enable-NestedVm.ps1 -OutFile ~/Enable-NestedVm.ps1

~/Enable-NestedVm.ps1 -VmName <VmName>

Далее создайте виртуальную машину на базе Windows 10 Build 10565, и включите в ней Mac Spoofing (если вы не сделали это в скрипте). Сделать это можно через настройки ВМ или следующей командой PowerShell:

Set-VMNetworkAdapter -VMName <VMName> -MacAddressSpoofing on

Ну а дальше просто запускайте виртуальную машину на виртуальном хосте Hyper-V:

После выхода новой версии платформы VMware vSphere 6 перед многими администраторами встал вопрос об обновлении различных компонентов виртуальной инфраструктуры. На крупных предприятиях, как правило, используется не только платформа VMware ESXi и сервисы управления vCenter, но и различные корпоративные продукты, такие как VMware Horizon View для инфраструктуры виртуальных ПК или VMware vRealize Operations (vROPs) для мониторинга и решения проблем.

Вот в какой правильной последовательности нужно обновлять решения VMware (если у нескольких продуктов очередь одна - их можно обновлять в любой последовательности):

О проведении операций по обновлению компонентов решений VMware более подробно рассказано в статье KB 2109760. Там же приведены примеры сценариев обновления, если у вас есть определенный набор продуктов.

Кстати, помните, что после обновления на VMware vSphere 6.0 вы не сможете использовать продукт VMware Storage Appliance, который больше не поддерживается.

Если вы хотите узнать совместимость различных продуктов для виртуальной инфраструктуры, воспользуйтесь ресурсом VMware Product Interoperability Matrixes.

Этой статьёй я хочу открыть серию статей, целью каждой из которых будет описание одной из написанных мной функций PowerCLI или так называемых командлетов (cmdlets), предназначенных для решения задач в виртуальных инфраструктурах, которые невозможно полноценно осуществить с помощью только лишь встроенных функций PowerCLI. Все эти функции будут объединены в один модуль - Vi-Module. Как им пользоваться, можете почитать здесь.

На проходящей сейчас в Барселоне конференции VMworld Europe 2015 компания VMware раскрыла окончательные подробности технологии vSphere Integrated Containers (VIC), которая позволяет работать с инфраструктурой виртуализованных приложений Docker на базе существующей виртуальной инфраструктуры VMware vSphere.

Начнем обзор технологии VIC вот с этого видео, в котором показано, как поднять nginx на Photon OS:

Ключевым понятием инфраструктуры контейнеров является VCH - Virtual Container Host. На самом деле это не хост, а виртуальный объект, состоящий из ресурсов ресурсного пула (Resource Pool) VMware vSphere или кластера хостов ESXi целиком. Это позволяет создавать контейнеры в нескольких доменах в рамках одного или нескольких VCH (например, Production, Staging и Test).

Каждый VCH обслуживает собственный кэш образов, которые загружаются из публичного хаба Docker или из частных репозиториев. Файловые системы ВМ в контейнерах размещаются в виртуальных дисках VMDK, которые уже лежат на обычных VMFS-хранилищах.

Само управление инфраструктурой VIC происходит через плагин к vSphere Web Client. Также есть интерфейс командной строки и PowerCLI. Вот, например, процесс создания VCH:

Напомним, что каждый контейнер Docker размещается в отдельной виртуальной машине. Сделано это с целью лучшей управляемости и надежной изоляции приложений для безопасной и стабильной их работы. Но это было бы слишком расточительно с точки зрения потребления ресурсов, поэтому VMware использует подход VMFork - создание мгновенных клонов работающей виртуальной машины. Например, вот тут мы как раз писали о VIC-подходе.

Photon Controller использует механизм VMFork (сейчас эта технология называется VMware Instant Clone и доступна в vSphere 6) для создания мгновенных экземпляров виртуальных машин на базе Photon OS (за менее, чем 1 секунду) с нужным приложением по запросу от пользователя.

То есть, на базе Photon OS развертывается новая машина через VMFork, а в ней уже тянется контейнер из нужного репозитория.

Linux-контейнеры требуют Linx Kernel и работают как приложения в виртуальных машинах, которые могут выполнять только обозначенную контейнером задачу и не имеют никаких лишних обвесов и интерфейсов.

Также для контейнеров мапятся стандартные команды, которые доступны для виртуальных машин (Power Off / Power On). Например, если мы выключим виртуальный контейнер, это будет означать, что виртуальную машину с контейнером на борту мы удалили.

vSphere Integrated Containers на данный момент находятся в статусе Technology Preview, об их доступности будет сообщено дополнительно.

Возможно не все из вас в курсе, что есть такая полезная и бесплатная утилита как vSphere Configuration Backup, которая позволяет просто и через GUI настроить резервное копирование и восстановление конфигурации серверов VMware ESXi и баз данных SQL.

Возможности утилиты:

• Автоматическое резервное копирование конфигов серверов ESXi 4, 5 и 6 (протестировано vSphere 4.1, 5.0, 5.1, 5.5, 6).
• Резервное копирование любой локальной базы данных и ее конфигурации.
• Управление точками восстановления и удаление устаревших бэкапов (только для бэкапов ESXi).
• Для всего бэкапа конфига ESXi создается только один файл.
• В имени архива бэкапа указан номер билда ESXi.
• Сжимает резервные копии конфигурации ESXi для экономии места на диске.
• Не требует установки.
• Шифрует пароли.
• Конфигурируется из GUI через Configuration Manager.exe.

Как пользоваться vSphere Configuration Backup:

• Запускаем "Configuration manager.exe" для настройки параметров.
• Добавляем хосты ESXi (добавлять vCenter нельзя).
• Выбираем БД SQL Server для резервного копирования.
• Устанавливаем папку для бэкапов и политику хранения резервных копий (сколько хранить и когда удалять).
• Создаем таску планировщика для запуска "ESXi Configuration Backup.exe".

Скачать vSphere Configuration Backup можно по этой ссылке.

Иногда администраторам хранилищ в VMware vSphere требуется передать логический том LUN или локальный диск сервера под другие цели (например, отдать не под виртуальные системы или передать в другой сегмент виртуальной инфраструктуры). В этом случае необходимо убедиться, что все данные на этом LUN удалены и не могут быть использованы во вред компании.

Раньше это приходилось выполнять путем загрузки из какого-нибудь Linux LiveCD, которому презентован данный том, и там удалять его данные и разделы. А в VMware vSphere 6 Update 1 появился более простой способ - теперь эта процедура доступна из графического интерфейса vSphere Web Client в разделе Manage->Storage Adapters:

Теперь просто выбираем нужный адаптер подсистемы хранения и нажимаем Erase для удаления логических томов устройства (будут удалены все логические тома данного устройства):

Теперь можно использовать этот локальный диск по другому назначению, например, отдать кластеру VSAN.

Ну и также отметим, что в следующей версии утилиты ESXi Embedded Host Client компания VMware сделает возможность не только удаления таблицы разделов, но и добавит средства их редактирования:

Как вы знаете, некоторое время назад компания VMware выпустила обновление платформы виртуализации vSphere 6 Update 1. После его выхода компания Veeam предупредила пользователей, что средство резервного копирования виртуальных машин Veeam Backup & Replication 8.0 пока не поддерживает последнее обновление от VMware. И вот на днях вышел Veeam Backup & Replication 8.0 Update 3 с полной поддержкой vSphere 6 Update 1. Так что большинство пользователей платформы ESXi может смело обновлять свою инфраструктуру.

Посмотрим на все новые возможности последнего обновления Veeam B&R:

Улучшения для Microsoft Windows:

• Поддержка Windows 10 в качестве гостевой ОС (включая обработку приложений - application-aware processing).
• Поддержка установки Veeam Backup & Replication и всех его компонентов на Windows 10.

Улучшения для VMware vSphere:

• Поддержка vSphere 6.0 Update 1.
• Возможность превратить предупреждение "VMware Tools not found" в информационное сообщение. Для этого параметр DisableVMwareToolsNotFoundWarning (REG_DWORD) в реестре нужно установить в значение 1.

Улучшения для Linux:

• Поддержка SSH-шифрования: aes128-ctr, aes192-ctr, aes256-ctr, aes192-cbc и aes256-cbc.

Новое у Veeam Explorer for Microsoft SQL Server:

• Лог транзакций для неподдерживаемых экземпляров SQL Server автоматически игнорируется, чтобы избежать сообщений об ошибке.
• Предпочитаемые сетевые настройки также применяются к задачам бэкапа транзакционного лога.

Новое у Veeam Explorer for SharePoint:

• Поддержка аутентификации ADFS
• Поддержка UPN credentials.

Улучшения SureBackup

• Модуль Proxy appliance теперь отвечает на пинг внутри виртуальной лаборатории (Virtual Lab), чтобы сетевые экраны не блокировали автоматически ее сеть как публичную.

Другое:

• Улучшено шифрование.
• Улучшена производительность операций консоли в больших окружениях.
• Уменьшена нагрузка на сервер SQL, а также увеличена надежность.
• Увеличена производительность настройки конфигурации резервного копирования для больших окружений.
• Прочие исправления ошибок в различных областях.

Скачать Veeam Backup & Replication 8.0 Update 3 можно по этой ссылке (нужно залогиниться).

Несколько лет назад мы писали про политики сложности паролей в VMware vSphere, которые определяют, какой пароль можно установить для пользователей ESXi. Аутентификация на ESXi реализуется с помощью подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM), которые обладают различными возможностями, такими как интеграция с Active Directory, большая устойчивость к подбору пароля и дополнительные возможности (например, задание сложности пароля для различных классов символов).

Разберем сначала структуру политики сложности пароля:

retry=3 min=N0,N1,N2,N3,N4

• retry=3 - допустимое число попыток ввода пароля.
• N0 - минимальная длина пароля, который имеет только символы из класса 1 (это символы букв в нижнем регистре - например, abc).
• N1 - это минимальная длина пароля, который обязательно имеет символы из двух классов (классы 1,2 и 3 - это символы букв в нижнем и верхнем регистре, а также цифры - например, abcABC).
• N2 - пароли, имеющие в составе слова, должны быть длиной не менее 8 символов. Например, vmwareee.
• N3 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2 и 3 (это буквы в нижнем и верхнем регистрах, а также цифры - например, abcABC123).
• N4 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2, 3 и 4 (это буквы в нижнем и верхнем регистрах, а также цифры и спецсимволы - например, abcABC123!).

Напомним политики паролей, которые были в VMware ESXi 5.x:

ESXi 5: retry=3 min=8,8,8,7,6

Это значит, что можно было:

• Задать пароль длиной в 8 символов из первого класса, например: thsmypwd
• Задать пароль длиной в 8 символов из первого и второго класса, например: thsmypwD
• Задать пароль из 8 символов, содержащем слово, например: vmwareee
• Задать пароль длиной в 7 символов из первого, второго и третьего класса, например: VMware1
• Задать пароль длиной в 6 символов из первого, второго и третьего класса, например: Vare1!

В VMware ESXi 6 политика сложности пароля была еще усложнена и теперь является такой:

retry=3 min=disabled,disabled,disabled,7,7

То есть, теперь пароль обязательно должен содержать минимум 7 символов, среди которых обязательно есть символы по крайней мере трех из четырех классов.

Но самое интересно, что политики сложности пароля ESXi теперь можно редактировать не в PAM-файлах сервисной консоли, а в расширенных настройках хоста в разделе Security (картинка кликабельна):

То есть, просто меняете параметр Security.PasswordQualityControl и перезагружаете хост ESXi.

Для массового изменения политик сложностей пароля можно использовать следующий PowerCLI-скрипт:

$PasswordPolicy = "retry=3 min=8,8,8,7,6"
$VMHosts = Get-VMHost | Where { $_.ConnectionState -eq "Connected" }
foreach ($VMHost in $VMHosts)
{
$VMHosts | Get-AdvancedSetting -Name "Security.PasswordQualityControl" | Set-AdvancedSetting -Value $PasswordPolicy -Confirm:$false
}

Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.

Начнем с того, что в целом все осталось как было:

Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:

• Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
• Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.

Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.

Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.

А вот как выглядит настройка ROBO-издания Virtual SAN:

Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.

Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.

Недавно мы писали том, что компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 версии 2.8. Эта версия прошла инспекционный контроль в ФСТЭК России и доступна для загрузки и покупки. В обновленную версию vGate R2 добавлены новые механизмы защиты и расширенные функции по администрированию системы. Сегодня мы расскажем о том, как в vGate R2 выглядит рабочий процесс для пользователей в защищенной среде.

Интересный пост, касающийся поддержки VMware Tools в смешнном окружении, опубликовали на блогах VMware. Если вы взглянете на папку productLocker в ESXi, то увидите там 2 подпапки /vmtools и /floppies:

Это файлы, относящиеся к пакету VMware Tools, устанавливаемому в гостевые ОС виртуальных машин. Перейдем в папку /vmtools:

Тут находится куча ISO-образов с данными пакета (каждый под нужную гостевую ОС), файл манифеста, описывающий имена, версии и ресурсы файлов пакета, а также сигнатура ISO-шки с тулзами, позволяющая убедиться, что она не была изменена.

В папке floppies находятся виртуальные образы дискет, которые могут понадобиться для специфических гостевых ОС при установке драйверов (например, драйвер устройства Paravirtual SCSI):

Интересно, что папка productLocker занимает примерно 150 МБ, что составляет где-то половину от размера установки VMware ESXi. Именно поэтому рекомендуют использовать образ ESXi без VMware Tools ("no-tools") при использовании механизма Auto Deploy для массового развертывания хост-серверов.

Самая соль в том, что версия пакета VMware Tools на каждом хосте разная и зависит от версии VMware ESXi. Например, мы поставили на хосте VMware vSphere 5.5 виртуальную машину и установили в ней тулзы. Консоль vCenter покажет нам, что установлена последняя версия VMware Tools:

Однако если у нас смешанная инфраструктура (то есть, состоит их хостов разных версий), то при перемещении машины на хост с более высокой версией, например, vSphere 5.5 Update 2/3, она будет показана как ВМ с устаревшей версией пакета (VMware Tools: Running (Out-of-Date):

Поэтому возникает некоторая проблема в смешанной среде, которую можно решить очень просто - как правило VMware Tools от хоста с большей версией подходят ко всем предыдущим. Например, тулзы от vSphere 6.0 подойдут ко всем хостам до ESXi 4.0 включительно. vSphere 6 Update 1 выпадает из списка (постепенно поддержка старых версий уходит):

Таким образом, лучше всего распространить тулзы от vSphere 6 на все хосты вашей виртуальной инфраструктуры. Для этого создадим общий для всех хостов датастор SDT и через PowerCLI проверим, что к нему имеет доступ несколько хостов, командой:

Get-Datastore | where {$_.ExtensionData.summary.MultipleHostAccess -eq “true”}

Далее создадим на этом датасторе папку productLocker:

в которую положим VMware Tools от ESXi 6.0:

Далее нужно пойти в раздел:

Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation

и вбить туда путь к общей папке, в нашем случае такой:

/vmfs/volumes/SDT/productLocker

Если вы хотите применить эту настройку сразу же на всех хостах кластера, то можно использовать следующий командлет PowerCLI:

Get-VMhost -Location <cluster name> | Set-VMHostAdvancedConfiguration -Name "UserVars.ProductLockerLocation" -Value "/vmfs/volumes/SDT/productLocker"

Теперь для применения настроек есть два пути: первый - это перезапустить хост ESXi, но если вы этого сделать не можете, то есть и второй путь - выполнить несколько команд по SSH.

Зайдем на хост ESXi через PuTTY и перейдем в папку с /productLocker командой cd. Вы увидите путь к локальной папке с тулзами на хосте, так как это ярлык:

Удалим этот ярлык:

rm /productLocker

После чего создадим новый ярлык на общую папку на томе VMFS с тулзами от vSphere 6.0:

ln -s /vmfs/volumes/SDT/productLocker /productLocker

Посмотрим, что все смонтировалось, командой ls:

Вот таким вот образом можно поддерживать самую последнюю версию VMware Tools в виртуальных машинах, когда в вашей производственной среде используются различные версии VMware ESXi.